SCCM OSD deployment onto Hyper-V Guest "Challenge"
Hello All,
I wonder if someone can offer any assistance with a "challenge" I have using SCCM OSD to deploy Windows 2003 R2 to a Hyper-V Guest.
We are using SCCM2007 SP1 (no R2 - 4.00.6221.1000) and have attempted to really restrict the usage of custom scripts within our deployment. We are also trying to keep our images down to a minimum so we have only 4 (x86/x64 STD/ENT) and are attempting to use these on all hardware types.
The issue is with driver support for Hyper-V. As you may or may not know, Hyper-V uses "synthetic" drivers based on the KMDF model. By default they don't work with WinPE nor within Windows 2003 (unless the Hyper-V integration services are installed).
MS offer a "Legacy" network adapter within Hyper-V as well (for the purpose of performing network builds) but I'd really don't want to use this because:
There would still have to be a set of manual steps to perform by the operator as (s)he swaps out the Legacy adapter for the synthetic one - and we wish to avoid the need for this.
There is no x64 driver for the legacy network adapter (see http://www.techlog.org/archive/2008/06/17/configmgr2007_build_and_captur)
I have got thus far:
Synthetic driver support within WinPE (following the guide here - http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/c997533e-7dec-4db0-bbad-25d852416167 - although I haven't created a custom WinPE image - I've added the drivers to SCCM and placed them in the boot image) - this work fine, including mouse and network support.
Synthetic driver support within Windows 2003 (this is only for the sysprep portion of the build until I can get the Intergration Services installed). http://www.techlog.org/archive/2008/06/17/configmgr2007_build_and_captur hilights a method to solve this, but this still doesn't give me everything I need as the drivers are not installed during mini-setup so the network card TS Variables "OSDAdapter0*" are not applied and the machine fails to join to the domain.
I have worked out that the file WdfCoinstaller01005.dll (the KMDF installer) from the integration services is really an archive, which contains the hotfix packaged file "Microsoft Kernel-Mode Driver Framework Install-v1.5-Srv2k3.exe" which (with a bit of tweaking as it misses installing the kernel mode service) can be integrated into the Windows 2003 R2 source I use to create my capture image - so the drivers I used from WinPE can be made into a driver package, and attempted to be detected during sysprep. However the build still fails.
The devices work by first presending the hardware ID of the root vmbus (root\vmbus) which once detected and working, presents the further hardware IDs (VMBUS\{GUID}) which include the network card. Within WinPE, all are detected as part of the boot up of the machine. However during Windows 2003 sysprep, only the VMBus is correctly detected, and the other devices are left with yellow bangs in device manager. Annoying once the build fails and I boot into Windows, when the shell (explorer.exe) starts, this forces the "new hardware wizard" to run and all devices are automatically detected.
I have even got as far as adding a cmdlines.txt to my C:\SYSPREP folder which calls "C:\WINDOWS\SYSTEM32\RunDll32.exe Syssetup.dll,UpdatePnpDeviceDrivers" (command obtained from http://www.msfn.org/board/lofiversion/index.php/t54353.html).This forces a second hardware renumerationthus the first SCCM boot into windows (after mini-setup completes) the devices are all working, but, still, as cmdlines.txt is processed last within mini-setup, the network card processing has already occured so my NIC doesn't get IP information and the build fails to join the domain.
I think this is because of the fact that the SCCM capture process doesn't reseal the machine with a -pnp switch - so an exhaustive hardware detection process doesn't occur.
Therefore my questions:
Does anyone know of a way to change the SYSPREP.EXE command line the "Capture the Reference Machine" presents so it includes a -pnp switch (or at least a way to fudge it after the event as this information must be burned into the WIM somewhere - perhaps a registry key)?
Does anyone know of a way to execute a command in mini-setup *before* SYSPREP starts (so there is a possibility that I can issue a driver detection first in the vain hope sysprep will find the network card and configure it)?
Or does anyone have any other ideas about how to fix the issue?
Thanks very much in advancePaul
July 4th, 2009 11:37am
(Just few thoughts...) Have you tried adding the integration components to the image? Yes this causes more images, but if you are using build and capture task sequences, this should be trivial and just a matter of disk space. Here's another guide on using the hyper-v drivers with WinPE: http://blogs.msdn.com/mikester/archive/2008/05/30/using-the-hyper-v-integration-components-in-winpe.aspx. You may want to revisit this one. One correction: sysprep does not run after mini-setup. Sysprep is run on the reference system and strips it of all unique identifiers including SIDs and then sets the OS to start mini-setup the next time it is booted. Mini-setup can use sysprep.inf to automated its tasks, but sysprep itself is done once it shuts the system down before this initial boot.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys
Free Windows Admin Tool Kit Click here and download it now
July 4th, 2009 4:57pm
Hello Jason,Thanks for the correction - it's noted.The guide you've linked to gives me the same level of detail about how to sort the problem for WinPE - which is indeed working. It doesn't help me within Windows 2003. Thanks for the link however.As for getting the Hyper-V drivers into the image - I have a completely automated task sequence to generate the images. I automate all steps (and have DHCP reservations setup in my lab subnet for this and have altered TSMBOOTSTRAP.INI with "Unattended=True") to the point where I literally have only to hit space bar to trigger the re-creation ofmy images.I do this (currently) on Windows VMWare Server 1.0.8 as both x64 and x86 images can be run without driver additions. If I wanted to switch to Hyper-V I'd surely be in the same position (e.g. my task sequence to create the image would fail from the point where the OS starts without a network driver because the integration services are not installed. Plus this (as you stated) meanstwice the number ofWIM files, and I really wanted to keep this to 4 (and have managed to get IBM physical andVMWare and MSVSvirtual support integrated into these already).I'm just stuck on the Hyper-V!cheersPaul
July 4th, 2009 8:58pm
Sussed it!Sysprep must reseal the image with a "-pnp" command. Otherwise an exhaustive driver detection is not performed during mini-setup and the additional drivers beyond the vmbus don't detect, and the sysprep.inf network settings are not transferred to the network card.In order to do this within SCCM (as there is no option within the GUI to perform this) the following registry keyis required:"HKLM\SYSTEM\Setup", "MiniSetupDoPnP", 1, "REG_DWORD"This is added into my image before Sysprep is executed - Sysprep never checks to delete this key when it's executed.After this, the drivers work correctly for long enough for me to get the Integration Services installed...
Free Windows Admin Tool Kit Click here and download it now
July 5th, 2009 10:41pm
What were the steps here http://www.techlog.org/archive/2008/06/17/configmgr2007_build_and_captur as that link no longer works.Jay Parekh Project Leadership Associates
May 31st, 2011 6:07pm